home *** CD-ROM | disk | FTP | other *** search
/ Linux Cubed Series 8: LINUX Games / Linux Cubed Series 8 - LINUX Games.iso / games / muds / pennmush.000 / pennmush-1.50-p8-linux.tar / pennmush / RWHO / README < prev   
Text File  |  1991-07-11  |  4KB  |  82 lines
  1. WARNING:::
  2. ----------
  3.  
  4.     DO NOT just run an mwhod on your local machine. You don't need it.
  5. Find where there is an existing mwhod and send rwho data to it. You NEED a
  6. password from that mwhod's adminstrator first, though!
  7.  
  8.     There is documentation on how to configure talking to an RWHO
  9. server in the UnterMUD distribution docs, in DOC/wizard/necronomicon.
  10.  
  11.  
  12.     There are LIMITED hooks into the server, use the USE_RWHO option,
  13. which requires modifying the Makefile.
  14.  
  15.     This code works, and well, but the timing/propagation timing needs
  16. to be adjusted.
  17.  
  18. mjr.
  19. clilib.c    - portable client interface (can be used with any MUD)
  20. muds.dat    - sample mwhod config for server sites
  21. mudwho.c    - client to talk to mwhod
  22. mwhod.c        - server source
  23. mwhocmd.c    - bare bones server command sender
  24. updat.c        - UnterMUD specific who-list update code
  25.  
  26.  
  27.     How the whole thing works:
  28.     --------------------------
  29.  
  30.     mwhod is a server that runs on a particular host and keeps a
  31. list of known MUDs. It is initially primed with a list of "trusted"
  32. MUDs and passwords used to authentication, and will accept information
  33. about who is logged into those MUDs. The server also has a notion of
  34. a "peer" server, which can transfer it (occasionally) a copy of all
  35. of it's list of who is logged on, and where. The idea is that the
  36. whole MUDding community could probably be served pretty well by about
  37. 4 top-level peer mwhods that kept eachother up to date about what
  38. each one is seeing.
  39.  
  40.     Communication between mwhods (and server updates sent to mwhods)
  41. is done with UDP datagrams, since they're fast, nonblocking, and
  42. throw-away. (I consider MUD rwho information to be interesting but not
  43. vital information, if you get my drift). Each MUD server only sends
  44. updates to a single mwhod, which may then propagate that information
  45. to its peers. This is done within the server as follows:
  46.  
  47.     - whenever the server boots, it sends a "hi there" packet to
  48.      the mwhod, telling it that it's up and running.
  49.     - whenever a player connects, it sends a "so and so is here"
  50.      packet to the mwhod, telling it that the user has connected.
  51.     - whenever a player disconnects, it sends a "so and so left"
  52.      packet to the mwhod, telling it to delete the entry.
  53.     - every so often ("so often" being defined as a time agreed
  54.      upon by the mwhod's owner, and the MUD's wizard) the MUD
  55.      sends a "hi there" packet and a complete list of everyone
  56.      that is on, just to refresh the mwhod's idea of who is
  57.      logged into that MUD.
  58.  
  59.     If a user connects to a specific port on an mwhod they are
  60. given a formatted dump of the mwhod's current table of MUDs and players,
  61. and then disconnected. "mudwho" is a simple little program that contacts
  62. the local mwhod and downloads this information. Ideally, the functionality
  63. of "mudwho" would be built into a player's client software, for ease of use.
  64.  
  65.     The mwhod does some clever stuff as far as eventually timing
  66. information about of its tables - for example, if it hears absolutely
  67. nothing from a MUD for a certain amount of time, it will mark the MUD
  68. as down. Player entries are expired similarly. The design is based on
  69. the idea that we'll use UDP to just fling information out and hope it
  70. sticks, and then let the recipient clean it up, rather than to develop
  71. a more complex protocol based on TCPs and timeouts. To prevent a packet
  72. circular send situation, each entry that is sent is given a "generation"
  73. number, which is incremented by one each time it is forwarded along. In
  74. this manner, a MUD server might send a "so and so is here" (generation
  75. zero) to its local mwhod. The local mwhod will eventually send a copy to
  76. any peers it may have (generation one), and so forth. Part of the initial
  77. table that an mwhod uses to establish what peers it trusts contains a
  78. generation value, and it will neither accept no propagate information
  79. to a specific peer that is of a higher generation value. This way, a
  80. "tree" of servers could theoretically be constructed, with the highest
  81. level one having a total view of a large MudIverse.
  82.